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Abstract of DEI 01 29237 

The circuit (1) has a number of adjacent cells 
(2a-2e) divided into at least 2 cell types, the 
cells having a sufficient size for integration of a 
number of logic elements (3a,3e), at least 
some of the cells having programmable logic 
elements. The terminals (5a-5d) for the 
interconnections betv/een the cells are 
positioned to allow mixing of the different types 
of cells within the cell matrix. An Independent 
claim for a design method for an integrated cell 
matrix circuit is also included. 
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(g) Verfahren zur Bearbeitung von Daten 

@ Die Erfindung betrifft ein Verfahren zur Obersetzung 
von Program men auf eIn System, bestehend aus wenig- 
stens einem ersten Prozessor und einer rekonfigurierba- 
ren Etnheit. Hierbei ist vorgesehen, daS die Codeteile, die 
fur die rekonfigurierbare Einheit geeignet sind, bestimmt 
und extrahiert warden und der verbleibende Code zur Ab- 
arbeitung durch den ersten Prozessor derart extrahiert 
wird. 
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Beschreibung 

[0001] Die vortiegende Erfindung befafit sich mit her- 
kommlichen, d. b. konventionellen und lekonfigunerbaien 
Architekluren sowie mil Verfahren hierfur, die cine Uberset- 
zung einer klassischen Hochsprache (PROGRAMM), wie 
Pascal, C, C-H-, Java, etc. ermoglichen, insbesondeie auf 
eine rekonfigurierbare Architektur. 

[0002] Unter einer konventionellen Prozessorarchitektur 
(PROZESSOR) werden vorliegend beispielsweise sequen- 
tielle Prozessoien mit einer von-Neumann- oder Havardar- 
chilektur verstanden, wie z, B. Kontroller, CISC-, RISC-, 
VLIW-, DSP- u, a. Prozessoren. 

[0003] Unter einer rekonfigurierbaren Zielarchitektur 
werden vorliegend Bausteine (VPU) nut konfigurierbarcr 
Funktion und/oder Vemetzung verstanden, insbesondere in- 
tegrierte Bausteine mit einer Mehizahl von ein- oder mehr- 
dimensional angeordneten, arithmetischen und/oder logi- 
schen und/oder analogen und/oder speichemden Baugrup- 
pen, die direkt oder dnrch ein Bussystem miteinander ver- 
bunden sind. 

[0004] Zur Gattung dieser Bausteine zahlra insbesondere 
systoiische Arrays, neuronale Netze, Mehrprozessor-Sy- 
steme, Prozessoren mit mehreren Rechenwerken und/oder 
logischen Zellen, Vemetzungs- und Netzwerkbausteine wie 
z. B. Crossbar-Schalter, ebenso wie bekannle Bausteine der 
Gattung FPGA, DPGA, XPUTER, etc. Hingewiesen vnxd 
insbesondere in diesem Zusammenhang auf die folgenden 
Schutzrechte desselben Anmelders: P 44 16 881.0-53, 
DE 197 81 412.3, DE 197 81 483.2, DE 196 54 846.2-53. 
DE 196 54 593.5-53, DE 197 04 044.6-53, 

DE 198 80 129.7, DE 198 61 088.2-53, DE 199 80312.9, 
FCTfDE 00/01869, DE 100 36 627.9-33, DE 100 28 397.7, 
DE 101 10530.4, DE 101 11 014.6, PCT/EP 00/105 16, 
EP 01 102 674.7. Diese sind hiermit zu Qfifenbarungszwek- 
ken voUumfanglich eingegliedert, 

[0005] Es hat sich gezeigt, daB es bestinrunte Verfahren 
und Programmablaufe gibt^ die sich besser mit einer rekon- 
figurierbare Architektur abarbeiten lassen als mit einer kon- 
ventionellen Prozessorarchitektur. Umgekehrt gibl es auch 
solche Verfahren und Programmablaufe, die besser mit einer 
konventionellen Prozessorarchitektur ausgefuhrt werden 
konnen. 

[0006] Die Aufgabe dieser Erfindung besleht darin Neues 

ftir die gewerbliche Anwendung bereitzustellen. 

[0007] Die Losung dieser Aufgabe wird in unabhangiger 

Form beansprucht. 

[0008] Es wurde erkannt, daB es wiinschenswert ist, daB 
Verfahren zur Datenverarbeitung so ausgelegt werden, daB 
nur die jeweils fiir die rekonfigurierbare Zielarchitektur be- 
sonders geeigneten Teile des zu ubersetzenden Programmes 
extrahiert werden. Die vorbleibendra Teile des Programmes 
konnen dann auf eine konventionelle Prozessorarchitektur 
iibersetzt werden. 

[0009] Weiterbin sei angemerkt, daB die Verfahren auch 
auf Gruppen von mehreren Bausteinen angewendet werden 
konnen. 

Systemaufbau 

[0010] Ein PROZESSOR wird derart mit einer oder meh- 
reren VPU(s) verbunden, daB ein efifizienter Informations- 
austausch, insbesondere in Form von Daten- und Statusin- 
formation moghch ist 

[OOU] Die Anordnung eines herkommlichen Prozessors 
und eines rekonfigurierbaren Prozessors, dergestalt, daB 
eine Daten- und Statusinformation zwischen denselben 
wahrend der Abarbeitung eines oder mehrere Programme 
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moglich ist und/oder ohne daB insbesondere die Datenverar- 
beitung auf dera rekonfigurierbaren Prozessor und/oder dem 
h^onunlicben Prozessor signifikant unterbrochen werden 
muB, sowie die Ausbildung eines d^artigen Systems soweit 
5 aus dem nachfolgenden ersichtiich, wild gleichfalls bean- 
sprucht. 

[0012] Es werden zunachsl beispielsweise folgende Ver- 
bindungsverfahren und -mittel verwendet: 

10 a) Shared-Memory 

b) Netzwerk (beispielsweise Bussysteme wie z. B. 
PCI-Bus, Serielle Busse wie z. B. Ethernet) 

c) Kopplung an einen internal Registersatz oder meh- 
rere interne Registersatze 

ts d) andere Speichermedien (Festplatte, Flash-ROM, 
etc.) 

[0013] Es sd erwahnt, daB bier als ein "Prozessor" auch 
ein Dual-Prozessorsystem und/oder ein andere Anordnun* 

20 gen aufweisendes System insbesondere mit mehr als zwei 
konventionellen Prozessoren gemeint sein kann. Gleichfalls 
und/oder altemativ sind mehrere rekonfigurierbare Bau- 
steine gleicbzeitig verwendbar. 

25 Ubersetzungsprinzip 

[0014] Aus einem PROGRAMM werden mittels eines 
PRAPROZESSORS die Teile extrahiert, die sich auf die je- 
weils bestimmte(n) VPU(s) effizient und/oder siimvoll ab- 
30 bilden lassen. Diese Teile werden in einem fiir VPUs geeig- 
neten Format ausgegeben (NML). 

[0015] Der verbleibende Code und/oder der extrahierte 
Code wird an der Stelle der durch die Extraktion fehlenden 
Code-Teile um einen Interface-Code erweitert, der entspre- 

35 chend der Architektur des Zielsystems die Kommunikation 
zwischen PROZESSOR(en) und VPU(s) steuert. Der ver- 
bleibende und ggf . erweiterte Code wird in Form einer klas- 
sischen Hochsprache ausgegeben (HOSTCODE), wobei die 
Gattung des ausgegebenen Codes insbesondere exakt der 

40 Gattung der urspningUchen HOCHSPRACHE entsprechen 
kann. 

[0016] Diese extrahierte HOCHSPRACHE wird mittels 
eines gewdhnlichen Standard-Ubersetzers fur den/die jewei- 
ligen PROZESSOR(en) ubersetzt, wobei es moglich ist, dies 
45 so zu gestaken, daB keinerlei besondere Anpassung des 
t)bersetzer5 an die va*wendete Datenveraibeitungsarchitek- 
tur notwendig ist. 

[0017] Durch dieses Verfahren wird der Implementie- 
rungsaufwand der Programmierumgebung erhebfich verein- 
50 facht. Zudem kann der Anwender den PROZESSOR weiter- 
bin in der ihm bekannten Programmierumgebung, die er frei 
wahlen kann, programmieren und debuggen. 

Obersetzungsablauf 

55 

Extraktion 

[0018] Zimachst wird der fiir eine VPU geeignet erschei- 
neadc Code aus dem PROGRAMM extrahiert. Die Extrak- 
60 tion kann auf unterschiedlichen Methoden basieren, die ein- 
zeln oder kombiniert angewendet werden. Folgende Metho- 
den sollen beispielbaft detaillierter beschrieben w^den. 

Extraktion durch Hints 

65 

[0019] Der Programmierer gibt explizit durch Hinweise 
(Hints) innerhalb des PROGRAMMES Anweisungen, wel- 
che Teile extrahiert werden sollen. Beispielsweise kann dies 
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foigendermafien erfolgen: 



Code 

5 

/ / STARr_NML_EXTRACnON 

Zu extrahieiender Code 

/ / END_NML_EXTRACnON 

Code 10 



7/START_NML_EXTRACT10N" kennzeichnet den Be- 
ginn eines zu extrahierenden Codes. 
7/END_NML_EXTRAC"nON" kennzddmet das Ende 
eines zu extrahierenden Codes. 

[0020] In einem solchen Fall ist die Binheit zur Umset- 
zung des Programms in Koniigurationscodes dazu ausgebil- 
det, die Hints beziebungsweise Umsetzungsvoigaben zu er- 
kennen. 

Extraktion duich Aufhif von NML-Routinen 

[0021] Der Programmierer implementierl Teile des PRO- 
GRAMMES direkt in NML und springt in die NML-Routi- 
nen durch Aufhife (calls). Beispielsweise erfolgt dies derart: 

a) NMI^Code 

procedure EXAMPLE 30 
begin 

end 

b) PROGRAMMCode 
Code 

call EXAMPLE / / Aufruf des NML^Codes 
Code 



Ubersetzung in NML 

[0025] Eine fur die implementierte VPU geeignete Uber- 
setzung des extrahierten Codes nach NML wird durchge- 
fuhrt 

[0026] Fur datenfluBorienti^te VPUs kann beispielsweise 
automatisch ein DatenfluB- und/oder KonLroLLHuBgrapfa auf- 
gebaut werden. Die Graphen werden dann in NML-Code 
iibersetzt. Dabei kann gegebenenfalls bereits das Abbilden 
auf die VPU erfolgen, beispielsweise mittels der Durchfuh- 
rung des Plazierens der benotigten Ressourcen und des Rou- 
tens der Verbindungen (Place and Route). Dies geschiehl 
zum Beispiel nach typischen bekannten Regeln des Plazie- 
rens und Routens. 



15 

Analyse 

[0027] Mittels einer automatiscben Analysemetbode wird 
der extrahieite Code und/oder der iibersetzte NMI^Code auf 
20 seine VSararbeitungseffizienz hin analysiert. Dabei ist die 
Analysemetbode bevorzugt so gewahlt, daB der Interface- 
Code und die daraus entstehenden Performanceeinfliisse an 
geeigneter S telle mit in die Analyse einflieBen. 
[0028] Gegebenenfalls wird die Analyse durch eine kom- 
25 plette Ubersetzung und Implementierung auf dem Hard- 
ware-System durchgefiihrt, indem das PROGRAMM ausge- 
fuhrt und mit geeigneten Methoden, wie sie beispielsweise 
nach dem Stand der Technik bekannt sind, vermessen wird. 



Loop 



[0022] In diesem Fall ist die Einheit zur Umsetzung dazu 
ausgebildet, NMLrProgrammteile, das heiBt Ptogrammteile 
zur Ausfiihrung in und/oder auf einem rekonfigurieibaren 
Array in dn grofieres Programm dnzubinden. 

Extraktion durch Analyse 

[0023] Durch an die jeweilig VPU angepaBte Analyseme- 
thoden werden Teile innerhalb des PROGRAMMES er- 
kannt, die effizient und/oder sinnvoll auf die VPU abbildbar 
sind. Diese Teile werden aus dem PROGRAMM extrahiert. 
[0024] Eine beispielsweise fur viele VPUs geeignete Ana- 
lysemetbode ist der Aufbau von DatenfluB- und/oder Kon- 
troUfluBgraphen aus dem PROGRAMM. Diese Graphen 
konnen binsichtlich ihier mdglichen Partittonierung und/ 
Oder Abbildung auf die Ziel-VPU automatisch untersucht 
werden. In diesem Fall w^en die Ibile der generierten 
Graphen bzw. die entspiechenden PROGRAMM-Teile, ex- 
trahi^; die sich hinieichend gut partitionieien und/oder ab- 
bilden lassen. Hierzu kann eine Partitionierbarkeits- und/ 
Oder Abbildbarkeitsanalyse erfolgen, die die jeweilige Ei- 
genschaft bewertet. 



[0029] Basierend auf den durchgeftihrten Analysen» kon- 
nen verschiedene durch die Extrakticn fur eine VPU ge- 
wahlte Teile als ungeeignet identifiziert werden. Umgekehrt 
35 kann die Analyse ergeben, daB bestimmte fur einen PRO- 
ZESSOR extrahierte Teile zur Ausfiihrung auf einer VPU 
geeignel waren. 

[0030] Eine option ale Schleife, die nach der Analyse ba- 
sierend auf geeigneten Entscheidungskriterien zuriick in den 
40 Extraklionsteil fuhrt, um diesen mit entsprechend der Ana- 
lyse angepaBten Extraktionsvorgaben emeul auszufuhren, 
ermoghcht die Optimierung des Ubarsetzungsergebnisses. 
Man hat somit eine Iteration. 

[0031] Die Schleife kann an mehreien unterscbiedlichen 
45 Stellen in den Compileriauf eingebracht sdn. 

Einbindung der PROZESSOR- und VPU-Compiler 



[0032] Der ausgegebene Code ist iiblicherweise vollstan- 
50 dig und ohne weitere Eingriffe auf den jeweils nachfolgen- 
den Compilem ausfuhrbar. Gegebenenfalls warden Compi- 
lerflags und Constraints fur die nachfolgenden Compiler ge- 
neriert, wobei der Anwender optional eigene Vorgaben hin- 
zuftigen und/oder die generierten Vorgaben modifizieren 
55 kann. Die nachfolgenden Compiler benotigen keine wesent- 
lichen Modifikationen, sodaB Standard-lbols einselzbar 
sind. 

[0033] Das voigeschlagene Verfahren eignet sich somit 
beispielsweise insbesondeie ak PrSprozessor vor Compilem 
60 und Entwicklungssystemen. 

Interface-Code 

[0034] Der Interface-Code, der in den extrahierten Code 
65 eingesetzt wird, kann durch unterschiedliche Verfahren vor- 
gegeben werden. Bevorzugt wild der Interface-Code in ei- 
ncr Datenbank abgelegt, auf die zugegriflfen wird. Die Ein- 
heit zur Umsetzung kann so ausgebildet sein, daB sie eine 
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Auswahl des Programinieiers beriicksichtigt, der beispiels- 
weise durch Hinwdse im PROGRAMM oder durch Compi- 
lerflags den passeoden Interface-Code auswahlL Dabei kann 
der fur das jeweils verwendete Implementierungsverfahren 
geeignete Interface-Code gewahlt werden. 
[0035] Die Datenbank selbst kann durch unterschiedliche 
Methoden aufgebaut und gewartet werden. Einige Beispiele 
sollen zur Verdeutlichung der Moglichkeiten angefiihrt wer- 
den: 

a) Der Interface-Code kann vom Lieferanten des Com- 
pilers fiir bestinunte Verbindungsverfahren vorgegeben 
werden. Dies kann bei der Organisation der Datenbank 
beriicksichtigt werden, indem entsprechende Speicher- 
raittel fiir diese Angaben bereitgehalten werden. 

b) Der Interface-Code kann vom Benutzer, der den Sy- 
stemaufbau bestimmt hat, selbst gescbrieben oder aus 
bestehenden (Beispiel-) Interface-Codes modifizierl 
und der Datenbank zugeftigt werden. Das Datenbank- 
mittel wird hierzu bevorzugt benutzermodifizierbar ge- 
staltet, um dem Benutzer die Datenbankmodifikation 
zu ermoglichen. 

c) Der Interface-Code kann von einem Entwicklungs- 
system, mil dem beispielsweise der Systemaufbau ge- 
plant und/oder beschrieben und/oder getestet wurde, 
automatisch generiert werden. 

[0036] Der Interface-Code ist gewohnlicherweise derart 
gestaltet, daB er den Anforderungen der Program mierspra- 
che entspricht, in der der extrahi^e Code vorliegt in den der 
Interface-Code eingefugt werden soil. 

Debugging und Integration der Toolsets 

[0037] In die Interface-Codes konnen Kommunikations- 
routinen eingefuhrt werden, um die unterschiedlichen Ent- 
wicklungssysteme fiir PROZESSOR und VPU zu synchrcH 
nisieren. Insbcsondorc kann der Code fiir die jeweiligen De- 
bugger aufgenonunen werden. 

[0038] Der Interface-Code steuert den Datenaustausch 
zwischen PROZESSOR und VPU. Er ist daher eine geeig- 
nete und bevorzugte Schnittstelle, um die jeweiligen Ent- 
wicklungssysteme und Debuggets zu steuem. Bs ist bei- 
spielsweise moglich, einen Debugger fur den PROZESSOR 
solange zu aktivieren, wie die Daten von dem Prozessor ver- 
arbeitet werden. Sobald die Daten iiber den Interface-Code 
an eine (oder mehrere) VPU ubergeben werden, ist ein De- 
bugger fur VPUs zu aktivieren. Wird der Code zuriick an 
den PROZESSOR gesendet, soil wiederum der PROZES- 
SOR-Debugger aktiviert werden. 

[0039] Es ist daher also moglich und bevorzugt, derartige 
Ablaufe durch das Einfiigen von Steuercodes fiir Debugger 
und/oder Entwicklungssysteme in den Interface-Code abzu- 
wickeln, 

[0040] Die Kommunikation und Steuerung zwischen den 
unterschiedlichen Entwicklungssystemen soil daher bevor- 
zugt mittels in die Interface-Codes von PROZESSOR und/ 
Oder VPU eingebrachte Steuercodes abgewickelt werden. 
Die Steuercodes konnen dabei bestehenden Standards fiir 
die Steuerung von Entwicklungssystemen weitgehend ent- 
sprechen. 

[0041] Die Vmvaltung und Kommunikation der Entwick- 
lungssysteme wird vorzugsweise wie beschrieben in die In- 
terface-Codes abgewickelt, kann jedoch - sofem sinnvoU - 
auch getrennt von diesen, nach einem entsprechenden Shnli- 
chen Verfahren abgewickelt werden. 
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Beschreibung der Figuren 

[0042] Fig. 1 verdeutlicbt das voigeschlagene Verfahren 
und zeigt einen moglichen Systemaufbau. Dabei ist ein 
5 PROZESSOR (0101) uber ein geeignetes Interface (0102) 
zum Dalen- und Statusaustausch mil einer VPU (0103) ver- 
bunden. 

[0043] Ein PROGRAMM-Code (0110) wird in einen fiir 
den PROZESSOR geeigneten Teil (0111) und einen VPU- 

10 geeigneten Teil (0112) zerlegt. 

[0044] OUl wird durch einen Standard-Compiler (0113) 
ubersetzl, wobei zusatzlicher Code zur Beschreibung und 
Verwaltung des Interfaces (0102) aus einer Datenbank 
(0114) eingefugt wird. Auf 0101 ausfuhrbarer sequentieller 

15 Code wird generiert (0116) und sofem notwendig die ent- 
sprechende Programmiorung (0117) des Interfaces (0102). 
[0045] 0112 wild durch einen VPU-Compiler (0115) iiber- 
setzt, wobei ein zusatzlicher Code zur Beschreibung und 
Verwaltung des Interfaces (0102) aus einer Datenbank 

20 (0114) eingefugt wird. Auf 0103 ausfuhrbare Konfiguratio- 
nen werden generiert (0118) und sofem notwendig die ent- 
sprechende Programmierung (0119) des Interfaces (0102). 
[0046] In Fig. 2 ist beispielhaft ein prinzipieller Ablauf ei- 
nar Compilation dargestellt Ein PROGRAMM (0201) wird 

25 in der Extraktionseinheit (0202) nach unterschiedlichen Ver- 
fahren in VPU-Code (0203) und PROZESSOR-Code (0204) 
zerlegt. Unterschiedliche Methoden konnen in beliebiger 
Kombination zur Extraktion angewendet werden, beispiels- 
weise Hinweise im urspriinglichen PROGRAMM (0205), 

30 Unterprogrammaufrufe (0206) und/oder Analyseverfahren 
(0207). Der jeweils extrahierte Code wird ggf ubersetzt und 
ggf auf seine Eignung fiir das jeweilige Zielsystem bin 
uberpnift (0208). Dabei ist eine Riickkopplung (0209) auf 
die Extraktion moglich, um Verbesserungen durch eine ge- 

35 anderte Zuordnung der Codes zum PROZESSOR oder einer 
VPU zu erhalten. 

[0047] Danach (0211) wird 0203 durch den Interface- 
Code aus einer Datenbank (0210) erweitert (0212) und/oder 
0204 wird durch den Interface-Code aus 0210 zu 0213 er- 
40 weitert 

[0048] Der entstandene Code wird auf seine Performance 
analysiert (0214), ggf. ist eine Riickkopplung (0215) auf die 
Extraktion moglich, um Verbesserungen durch eine gean- 
dorte Zuordnung der Codes zum PROZESSOR oder einer 

45 VPU zu erhalten. 

[0049] Der entstandene VPU-Code (0216) wird fur eine 
weitere Ubersetzung an einen nachgeschalteten fiir die VPU 
geeigneten Compiler weiteigegeben. Der entstandene PRO- 
ZESSOR-Code (0217) wird fiir die weitere XJbersetzung in 

50 einem beliebigen nachgeschalteten fiir den PROZESSOR 
geeigneten Compiler weilerverarbeitet. 
[0050] Es soli angemerkt werden, daB einzelne Schritte je 
nach Verfahren ausgelassen werden konnen. Wesentlich ist, 
daB weitgehend kompletter und ohne Eingrifif durch den 

55 Programmierer direkt iibersetzbarer Code an die jeweils 
nachgeschalteten Compilersysteme ausgegeben wird. 
[0051] Die Datenbank fiir die Interface-Codes (0210) wird 
unabhangig und vor dem Compilerdurchlauf aufgebaut. 
Beispielsweise sind folgende Quellen fur die Datenbank 

€0 moglich: Vom Lieferanten vorgegeben (0220), vom Benut- 
zer programmiert (0221) oder automatisch vchi einem Ent- 
wicklungssystem generiert (0222). 

[0052] Zusammenfassend befaBt sich die vorliegende Er- 
findung mit Verfahren, die eine Ubersetzung einer kiassi- 
65 scben Hochsprache wie Pascal, C, C-H-, Java, etc. auf eine 
rekonfigurierbare Architektur ermoglicht. Das Verfahren ist 
dCTart ausgelegt, daB nur die jeweils fiir die rekonfigurier- 
bare Zielarchitektur geeigneten Teile des zu iibersetzenden 



DE 101 29 

7 

PFogrammes extrahiert werden. Die verbleibenden Teile des 
Programmes weiden auf eine konventionelle Plrozessorar- 
chitektur ubersetzt 

Patentanspriiche 5 

1 . Verfahren zur Ubersetzung von ProgrammeD auf ein 
System bestehend aus wenigstens einem ersten Prozes- 
sor und einer rekonfigurierbaren Einheit, dadurch ge- 
kennzeichnet, daB die Codeteile, die fiir die rekonfigu- to 
rierbare Einheit geeignet sind, beslinmit und extrahiert 
weiden und der veibleibende Code zmt Abarbeitung 
durch den ersten Prozessor derart extrahiert wird. 

2. Verfahren nach Anspruch I, dadurch gekennzeich- 
net, daB dem fiir den Prozessor extrahierten Code der- 15 
art Interface-Code zugefugt wild, daB eine Kommuni- 
kation zwischen Prozessor und rekonfigurierbarer Ein- 
heit entsprechend des Systems moglich ist. 

3. Verfahren nach einem der vorfiergehenden Ansprii- 
che, dadurch gekennzeichnet, daB dem fur die rekonfi- 20 
gurierbare Einheit extrahierten Code derart Interface- 
Code zugefugt wird, daB eine Kommunikation zwi- 
schen Prozessor und rekonfigurierbarer Einheit ent- 
sprechend des Systems moglich ist, 

4. Verfahren nach einem der vorhergehenden Anspru- 25 
che, dadurch gekennzeichnet, daB der zu extrahierende 
Code aufgrund von Analysen festgestellt wird. 

5. V^ahren nach einem der vorhergehenden Ansprti- 
che, dadurch gekennzeichnet, daB der zu extrahierende 
Code aufgrund von Hinweisen im Code festgestellt 30 
wird. 

6. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, daB der zu exU^ierende 
Code aufgrund von Aufrufen von Unlerprogrammen 
festgestellt wird. 35 

7. Verfahren nach einem der vorhergehenden Ansprii- 
che, dadurch gekennzeichnet, daB der Interface-Code 
eine Speichexkopplung (Shared-Memory) voi^ieht. 

8. Verfahren nach einem der vorfiergehenden Ansprii- 
che, dadurch gekennzeichnet, daB der Interface-Code 40 
eine Registericopplung vorsieht. 

9. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, daB der Interface-Code eine Kopplung mittels ei- 
nes Netzwerkes vorsieht 

10. Verfahren nach einem der vorhergehenden An- 45 
spriiche, dadurch gekennzeichnet, daB der extrahierte 
Code analysiert wird und gegebenenfalls die Extrak- 
tion mil neuen verbesserten Parametem emeut gestartet 
wird. 

11. Verfahren nach Anspruch 1, dadurch gekennzeich- 50 
net, daB dem extrahierten Code Steuer-Code zur Ver- 
waltung und/oder Steuerung und/oder Kommunikation 
der Entwicklungssysteme zugefugt wird. 

12. Verfahren nach einem der vorhergehenden An- 
spritohe, worin der erste Prozessor eine konventionelle 55 
I^zessorarchitektur -aufweist, insbesondere ein Pro- 
zessor mit von -Neumann- und/oder Harvardarchitek- 
tur, KontroUer, QSC-, RISC-, VLIW-, DSP-Prozessor. 

13. Verfahren insbesondere nach einem der vorherge- 
henden Anspriiche zur Ubersetzung von Programmen 60 
auf ein System bestehend aus einem Prozessor und ei- 
ner rekonfigurierbaren Einheit, dadurch gekennzeich- 
net, dafi 

die Codeteile, die fiir die rekonfigurierbare Einheit ge- 
eignet sind, extrahiert werden, 65 
der verbleibende Code derart extrahiat wird, daB er 
mittels eines beliebigen gewohnlichen unmodifizierten 
fiir den Prozessor geeigneten Compilers ubersetzbar 
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ist. 

14. Vorrichtung zur Datenverarbeitung mil wenigstens 
einem herkommlichen Prozessor und wenigstens einer 
rekonfigurierbaren Einheit, dadurch gekennzeichnet, 
daB sie ein Mittel zum Informationsaustausch, insbe- 
sondere in Form von Daten- und Statu sinformation 
zwischen herkommlichem Prozessor und rekonfigu- 
rierbarer Einheit aufweist, wobei das Mittel so ausge- 
bildet ist, daB eine Dalen- und Statusinformation zwi- 
schen denselben wahrend der Abarbeitung eines oder 
mehrerer Programme moglich ist und/oder ohne daB 
insbesondere die Datenverarbeitung auf dem rekonfi- 
gurierbaren Prozessor und/oder dem herkommlichen 
Prozessor signifikant unt^brochen werden muB. 
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